Summary

Fixes #47356.

A session-enabled ServiceBusProcessorClient (PEEK_LOCK) that settles messages manually inside the handler — e.g. calling context.complete() — while auto-complete is left enabled (the default) intermittently logged a spurious error at ERROR:

c.a.c.a.implementation.handler.ReceiveLinkHandler2 - {"az.sdk.message":"Cannot process the
disposition request to set the state as 'Accepted{}' for the delivery with delivery tag (id)
'...'. Reason: The delivery with the delivery tag does not exist in the link's DeliveryMap.", ...}

The message is already settled correctly on the broker; the only symptom is this misleading DeliveryNotOnLinkException log line (one per message). No messages are lost or redelivered, and processError is not invoked.

Root cause

The processor's auto-disposition feature settles a message after the handler returns. When the handler also settles manually, two dispositions are issued for the same delivery. The SDK is designed to absorb this redundant settle via the message.isSettled() guard in updateDisposition:

} else if (message.isSettled()) {
    return Mono.error(new IllegalArgumentException("The message has either been deleted or already settled."));
}

The non-session and V1-session paths arm this guard by calling message.setIsSettled() on a successful disposition (ServiceBusReceiverAsyncClient). The V2 session path (SessionsMessagePump.SessionReceiversTracker.updateDisposition) never did. So the flag stayed false, the guard could not trip, and the redundant auto-complete proceeded to a second link-level disposition on a delivery that had already been removed from the DeliveryMap — producing the DeliveryNotOnLinkException ERROR.

Fix

Mark the message settled on a successful disposition in the V2 session path, mirroring the sibling paths:

updateDispositionMono = receiver.updateDisposition(message.getLockToken(), deliveryState)
    .doOnSuccess(__ -> message.setIsSettled());

This arms the existing isSettled() guard so a redundant settle short-circuits with the benign "already settled" error (swallowed at verbose by the auto-disposition wrapper) instead of reaching the receive-link. The change is package-local to azure-messaging-servicebus; no azure-core-amqp change is needed.

Verification

Reproduced live against a Standard namespace with a session-enabled subscription, sending 5 messages to one session and a session processor that calls complete() manually with auto-complete enabled.

The fix removes the error log with auto-complete still enabled (no customer config change required) and does not regress the manual-settlement path.

Notes for reviewers

• Using disableAutoComplete() remains the recommended pattern when settling manually; this PR additionally makes the SDK fail quietly and consistently on a redundant settle for session processors, matching the documented "auto-settle is tolerated" behavior already present in the other receive paths.
• CHANGELOG updated under 7.18.0-beta.2 (Unreleased) → Bugs Fixed.